Document management system and method

ABSTRACT

A system for managing documents at an electronic data repository includes an electronic data repository that is accessed by a plurality of parties that are remote from a repository and from each other and that have a roll in a transaction. A computer program receives a document from a first remote party and stores the received document in the repository. The computer program permits one or more of the parties access to the document and prohibits all of the parties from modifying and deleting the document from the repository while any second remote party has access to the document.

The present application is a continuation of U.S. application Ser. No.11/633,348, filed Dec. 4, 2006, which is a continuation of U.S.application Ser. No. 10/160,478, filed May 31, 2002 (now U.S. Pat. No.7,146,367), which claims the benefit of U.S. provisional applicationSer. No. 60/381,007, filed on May 14, 2002, the entire disclosure ofeach of which is hereby incorporated by reference herein.

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by any-one of the patentdocument or the patent disclosure, as it appears in the Patent andTrademark Office patent file or records, but otherwise reserves allcopyright whatsoever.

BACKGROUND OF THE INVENTION

The present invention relates generally to systems and methods forelectronically managing information.

It is common in business transactions involving multiple parties for theparties to share documents generated in the transaction. Typically, oneor more parties make hard copies of various documents, distribute themas needed and revise documents as the transaction proceeds. Accordingly,it may be difficult at any given time to identify the currently validdocument or for any two remote parties to be sure that their respectivecopies of a given document are the same.

Document imaging, storage and management systems are known. Generally,however, these systems are internal to a given party and do not providedocument access to other parties. Furthermore, it is also known for abusiness entity to establish an extranet by which its clients andcustomers can access information placed on the extranet by the party.Generally, however, these systems are controlled entirely by the hostparty. The external parties cannot add documentation, and they cannot besure of the consistency of the documents they review on the extranetover time.

SUMMARY OF THE INVENTION

The present invention recognizes and addresses the foregoingconsiderations, and others, of prior art constructions and methods.

Accordingly, it is an object of the present invention to provide animproved system and method for managing data items, for exampledocuments involved in a transaction.

This and other objects are achieved by a system for managing data itemsat an electronic data repository with respect to a plurality of parties.The system includes an electronic data repository and a computerprocessor programmed to receive data items from parties remote from therepository and from each other. The program stores the received dataitems in the repository. It provides each remote party access only tothose data items within one or more data item sets corresponding to theremote party. The program prohibits any remote party from modifying anydata item in the repository, and from deleting any data item from therepository, while the data item is part of a data item set of anotherremote party. A first remote party may access data items in a setcorresponding to a second remote party, responsively to the secondremote party.

In a computerized method for managing data items at an electronic datarepository with respect to a plurality of parties, data items arereceived from parties remote from the repository and from each other andare stored in the repository in an electronic format. Each remote partyis provided access only to those data items within one or more data itemsets corresponding to the remote party. Remote parties are prohibitedfrom modifying any data item in the repository, and from deleting anydata item from the repository, while the data item is part of a dataitem set of another remote party. A first remote party is permittedaccess to data items in a set of a second remote party, responsively tothe second remote party.

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate one or more embodiments of theinvention and, together with the description, serve to explain theprinciples of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

A full and enabling disclosure of the present invention, including thebest mode thereof directed to one of ordinary skill in the art, is setforth in the specification, which makes reference to the appendedFigures, in which:

FIG. 1 is a schematic illustration of an example of a document type andgroup definition for remote parties to a transaction which might be usedin accordance with an embodiment of the present invention;

FIG. 2 is a schematic illustration of an example of a document sharingrelationship effected by one embodiment of the present invention;

FIG. 3 is a diagrammatic view of a document management system accordingto an embodiment of the present invention;

FIG. 4 is a diagrammatic view of a document management system accordingto an embodiment of the present invention;

FIG. 5 is an exemplary administrator screen display for use in anembodiment of the present invention;

FIG. 6 is an exemplary administrator screen display for use in anembodiment of the present invention;

FIG. 7 is an exemplary administrator screen display for use in anembodiment of the present invention;

FIG. 8 is an exemplary administrator screen display for use in anembodiment of the present invention;

FIG. 9 is an exemplary administrator screen display for use in anembodiment of the present invention;

FIG. 10 is an exemplary administrator screen display for use in anembodiment of the present invention;

FIG. 11 is an exemplary administrator screen display for use in anembodiment of the present invention;

FIG. 12 is an exemplary user screen display for use in an embodiment ofthe present invention;

FIG. 13 is an exemplary user screen display for use in an embodiment ofthe present invention;

FIG. 14 is an exemplary user screen display for use in an embodiment ofthe present invention;

FIG. 15 is an exemplary user screen display for use in an embodiment ofthe present invention;

FIG. 16 is an exemplary user screen display for use in an embodiment ofthe present invention;

FIG. 17 is an exemplary user screen display for use in an embodiment ofthe present invention;

FIG. 18 is an exemplary user screen display for use in an embodiment ofthe present invention;

FIG. 19 is an exemplary fax cover sheet generated by and for use in anembodiment of the present invention;

FIG. 20 is an exemplary scanning cover sheet generated by and for use inan embodiment of the present invention;

FIG. 21 is an exemplary user screen display for use in an embodiment ofthe present invention;

FIG. 22 is an exemplary scanning cover sheet generated by and for use inan embodiment of the present invention;

FIG. 23 is an exemplary screen display for use in an embodiment of thepresent invention;

FIG. 24 is an exemplary screen display for use in an embodiment of thepresent invention;

FIG. 25 is an exemplary screen display for use in an embodiment of thepresent invention;

FIG. 26 is an exemplary screen display for use in an embodiment of thepresent invention;

FIG. 27 is an exemplary screen display for use in an embodiment of thepresent invention;

FIG. 28 is an exemplary screen display for use in an embodiment of thepresent invention;

FIG. 29 is an exemplary screen display for use in an embodiment of thepresent invention; and

FIG. 30 is a diagram of an exemplary data hierarchy for use in anembodiment of the present invention.

Repeat use of reference characters in the present specification anddrawings is intended to represent same or analogous features or elementsof the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Reference will now be made in detail to presently preferred embodimentsof the invention, one or more examples of which are illustrated in theaccompanying drawings. Each example is provided by way of explanation ofthe invention, not limitation of the invention. In fact, it will beapparent to those skilled in the art that modifications and variationscan be made in the present invention without departing from the scope orspirit thereof. For instance, features illustrated or described as partof one embodiment may be used on another embodiment to yield a stillfurther embodiment. Thus, it is intended that the present inventioncover such modifications and variations as come within the scope of theinvention.

One or more embodiments of the invention described below operate withina distributed computing environment. Those of ordinary skill in this artshould understand that the examples described below are provided forpurposes of illustration only and that the present invention may beembodied in various suitable environments.

A distributed computing environment generally includes multiple memorystorage and computing devices located remotely from each other.Execution of program modules may occur at these remote locations as datais transferred among the memory devices and by and between the computingdevices over an extended network.

Generally, the present invention is described herein as used by remoteparties. This does not refer to the parties' physical relationship, butinstead indicates that the parties do not have control over a repositorydatabase(s) in which documents are stored or the server that controlsthe repository database. In addition, the parties may be remote fromeach other, not necessarily indicating spatial separation, but insteadindicating that no party has control of another party's database or of aserver that controls the other party's database. Thus, the partiescontrol only their access to documents in the repository database(s),not the integrity of the stored documents themselves.

Communication among such parties may be, for example, through theInternet, which is a global accumulation of computing devices thatcommunicate through an information retrieval system, most commonly theWorld Wide Web (hereinafter “Web”). It should be understood, however,that an Internet-based system is merely one example of a suitableconstruction and execution of the present invention. For example, remoteparties may also communicate among the parties' individual local or widearea networks through a private network structure.

Certain operations and processes described herein are executed by one ormore computers within a distributed computing network. As should be wellunderstood, a computer transforms information in the form of electronicsignals input into the computer to a desired output. The input may beprovided by a human operator, another computer, or from other externalstimuli. To accomplish these functions in one computing environment, aconventional personal computer includes a processor, read-only andrandom-access memory, a bus system and an input-output system totransfer information within the personal computer and to interact withexternal devices. The computer's memory includes an operating system andvarious application programs that run on the operating system.Application programs may be added to memory from external devices, forexample through the Internet, and may be run on the operating systemfrom an external device or from a device hosted by the computer, forexample a disk drive or CD ROM drive.

The computer's memory may include an application program for browsingthe World Wide Web. The browser, which may reside on a server in a localarea network or in a stand-alone computer, establishes communicationbetween a Web server and the computer. In response to receipt of aUniform Resource Locator (“URL”), the browser establishes a network pathto a Web server identified by the URL. Once connected, the computer andthe Web server may communicate with each other using the HypertextTransfer Protocol (“http”). For example, the Web server may transfer Webpages, including text and graphic images, and sound and video filesusing a standard description language such as Hypertext Markup Language(“html”). The Web page may provide “links” to other files and to otherservers. The links may be provided as options to the user so that theuser may choose to execute the link, or an application program operatedby the computer may execute the link without the user's knowledge. Theapplication program may be hosted by the Web server or by a networkdriven by the Web server and operated by the user over the Internetthrough the Web browser. The Web server in such an environment islocated at an application service provider (“ASP”), an arrangement thatshould be well understood by those skilled in this art.

It should be understood that the Web server may dynamically produce Webpages by script execution or may transmit scripts or other programs forexecution by the Web browser.

It should also be understood that communication between the host andclient sites may be effected through html, xml or other suitable dataformat.

A. System Overview

The present invention is described herein within the context of mortgagetransactions. It should be understood, however, that this is provided byway of example only and that the present invention may be used inmanaging electronic data items within other types of environments.Existing home owners and home buyers typically obtain mortgages throughdirect contact with a lender or through a mortgage broker. Where abroker is used, and referring to FIG. 1, a mortgage broker initiallyrequests that the loan applicant complete loan application documents,indicated at 10, which may include federally standardized forms. Thebroker also obtains credit report documents 12, which may include areport of the applicant's credit worthiness and an authorizationdocument signed by the applicant providing the broker permission toobtain applicant's credit information and to provide applicant's creditinformation to lenders and other parties involved in the mortgagetransaction.

Ultimately, the broker attempts to match the home owner or buyer with alender. From application documents 10 and credit report documents 12, abroker may be able to determine which lenders are most likely or bestsuited to provide a mortgage to the applicant. The various lenders,however, may require somewhat different documentation, and the brokermay therefore require varying information and papers from the applicantdepending on which lender the broker initially contacts. Typically,however, lenders require income-related documents 14, for example W-2forms and pay stubs, and a property appraisal 16.

The broker provides these documents to the lender, as indicated by theright-pointing arrows 17, who in turn puts together a loan originationpackage. In the subsequent underwriting process, the lender mayadditionally generate a variety of forms 18 solely for its internal use.After determining whether it wishes to grant or deny the loan, thelender generates an approval/denial statement 20. The lender provides acopy of the approval/denial statement to the broker, as indicated byarrow 22, so that the broker may notify the mortgage applicant. If theloan is approved by the lender, the broker's role is largely complete,and there is therefore little or no document sharing between the brokerand other parties as the mortgage transaction proceeds. If, however, theloan is denied by the lender, the broker typically contacts a differentlender, repeating the process until a lender is found that will approvethe application. It should be noted that any party that reviews thedocumentation associated with an application is required to maintaincopies of those documents for some period of time as required by theapplicable regulations. In other words, any lender that reviews anapplication must keep copies of the application documents regardless ofwhether that lender ultimately approves the loan. The same requirementsapply to a broker, regardless of whether that broker is ultimately ableto locate a suitable lender.

Assuming the lender approves the mortgage request, the lender preparesvarious documents 24 executed between the applicant and the lender atclosing of the mortgage.

If the lender maintains the mortgage in-house, the lender continues tomanage the mortgage until resolved by the applicant. Often, however,lenders sell loan packages to larger investors such as FREDDIE MAC orFANNIE MAE. Alternatively, a lender may outsource the mortgage to aservice provider that handles collection of the home owner's mortgagepayments for an agreed-upon fee. In either case, the investor typicallyrequires origination and closing documents from the lender in order toassess the advisability of taking the mortgage, as indicated at 26 and30. The investor may require at 28 the approval/denial statement as partof its origination documents, although it typically would not beprovided the lender's internal underwriting documents.

As described in more detail below, in a preferred embodiment of theinvention, an image or other electronic format of each of the documentsin FIG. 1 is stored in a single repository, which may comprise a singleserver and database site or multiple servers and/or databases, indicatedat 32 in FIG. 2. For purposes of simplicity, FIG. 2 illustrates onlyfive documents 34 a-34 e, although it should be understood that alldocuments shown in FIG. 1 may be stored at the repository. Similarly,FIG. 2 illustrates only two remote parties, for example broker 36 andlender 38, although it should be understood that various other partiesmay be included.

Both parties to the transaction store documents to, and view documentsin, the repository over a remote connection such as the Internet, asindicated by arrows 40. As shown in FIG. 2, for example, broker 36 hassaved documents 34 a, 34 b, 34 c and 34 e. Lender 38 has stored document34 d. Once stored in the repository, neither party, even the party thatinitially created and stored the document, can delete the document fromthe repository if access to that document is required by another party.Likewise, once a document is added to the repository, it is not possiblefor any party to revise or replace that document. A revised version can,however, be stored as a new document.

When a party requests a document from the repository, the system hostserver provides a Web page displaying an image (e.g. in PDF format) ofthat document to the party. Each transaction party may define anorganization by which the system presents the document images to one ormore users at the transaction party site. Such an organization isreferred to herein as a “view” and, as described in more detail below,each party may organize documents into document types which are in turnorganized into document groups. Thus, each party may organize its accessto the repository documents into groups that suit its needs. That is, inits view(s), the repository documents to which the party's users haveaccess are organized in a manner suitable to how that party conductsbusiness.

In the preferred embodiment described herein, the document organizationsdefined within a given party's views do not affect the organization ofthe documents in the repository. Each party's users view the repositorydocuments as if they were grouped according to the party's particularneeds. Referring to the example provided in FIG. 1, each columnrepresents the respective views of the broker, lender and investor tothe documents stored in the repository. The repository, however,contains only a single document image for each indicated document. Thatis, the repository contains only a single instance (in an image or otherelectronic format) of the Form 1008 document shown in each view.

A view may be unique to the transaction party. The broker in FIG. 1, forexample, organizes its view into groups identified as applicationdocuments, credit report documents, income documents and otherdocuments. Each group is associated with one or more document types, forexample Forms 1008 and credit reports. From the lender's perspective,however, all of these document types relate to loan origination and aretherefore grouped in its view under an “origination” group. For itspart, the lender categorizes certain other documents as relating tounderwriting and closing—groups not applicable to the broker.

As described in more detail below, a party storing a document into therepository may grant access to that document to any other party, and thesystem maps the document images from the source party's view to thereceiving party's view. Once a party has been granted access to adocument, it may likewise grant access to any other party, regardless ofwhether the former party initially stored the document in therepository. Accordingly, document access may be established as neededduring a transaction's progression, even though the transaction movesbeyond the originating party.

Once a party has access to a document in the repository, the party mayremove the document from its view, but this does not affect access tothat document by the other parties. In one preferred embodiment asdescribed herein, no single party controls when a document is deletedfrom the repository. Thus, “removal” of a document as described in theexample below refers to deletion of access to a particular document onlyfrom that party's view. After deletion, if the party wishes tore-establish the document within its view, another party currentlyhaving access to the document may provide access. If and when allparties have removed a particular document from their respective views,the system may purge the document from the repository at its discretion.

FIG. 3 illustrates one exemplary environment of the present invention inwhich remote parties communicate with the repository over the Internet.A host system 40 hosts server-side software at a primary server 42 withwhich a plurality of client work stations 44 communicate via theInternet 46. In one embodiment, primary server 42 includes dual 750 MHzPENTIUM III processors, with 2 gigabyte RAM and RAIDS storage. Server 42stores and manages data through an SQL database 48. Database 48 isseparated from server 42 for purposes of illustration, although itshould be understood that the database and server can be embodied by thesame hardware. The repository may generally be considered to include theSQL server database, document storage and document images. Anadministrator may communicate with server 42 and database 48 through anadministrator workstation 50, for example a personal computer.

Client systems 44 may each include a workstation 52. Workstation 52 maybe, for example, a personal computer supporting an Internet browser suchas Internet Explorer 5.0, or higher version, available from MICROSOFTCORPORATION. In the presently described embodiment, workstation 52 alsosupports software for viewing PDF format images, such as an ADOBEACROBAT reader.

A transaction party may store documents in the repository at database 48through its workstation 52. The transaction party may acquire the imagethrough any suitable means, for example via a fax machine 56, a scanner58 or through uploading an existing electronic document from anotherstorage device.

FIG. 4 illustrates in block diagram form the administrative softwarehoused at primary server 42. For purposes of clarity, only one clientworkstation 44 is illustrated. Primary server 42 houses client interfacesoftware 62, for example written in VISUAL BASIC SCRIPT, that isexecuted by a MICROSOFT IIS Web Server to generate Web pages that aredownloaded to client systems 44 and through which the transactionparties communicate with host system 40. Working through such Web pages,the transaction parties may request that the host system retrieve adocument image stored in the repository. Responsively to such a request,client interface software 62 executes appropriate queries againstdatabase 48. Retrieving the document image, client interface 62downloads the image to the appropriate client workstation 52 in a Webpage through Internet 46.

As described below, a transaction party may submit a document to thesystem in any suitable format, for example an image or other electronicfile generated by fax, scan or electronic download. For each document,the transaction party provides a document type and destination folder(described below), although additional information may also be provided.In the presently-described embodiment, the transaction party may submitthe document image in a multi-page TIF format, optionally using barcodes to provide required information such as the document type and thedestination folder. In the case of a scanned image, local software atclient workstation 52 combines data read from bar codes with dataprovided interactively by the user and sends the scanned TIF image tothe host server along with the data identifying the document type,destination folder, the transaction party, and the date and time. Thehost server passes the file to indexing process 64 (which may be writtenin VISUAL BASIC and C++), which in turn stores the document image indatabase 48 in association with a document number, an origination dateand the folder defined by the originating transaction party and in whichthe document image will thereafter appear.

In the event a transaction party faxes a document image from a faxmachine 56 to fax server 59 through a dial-up connection, the fax isreceived through a modem connection by a fax server code module. The faxserver code is built, for example, from a FAXMAN tool kit available fromData Techniques, Inc. The fax server code communicates the faxed TIFfile directly to the indexing process. Alternatively, client fax machine56 may fax the document image to a fax service provider 67. The faxservice provider then emails the document image file and its associateddata to the host server through the Internet 46. The server passes thefile to indexing process 64 similarly to scanned images.

In the event a transaction party uploads an image document from a sourceother than fax machine 56 or scanner 58, client workstation 52 transfersthe image to the host server over the Internet 46 through an http orhttps connection. The host server then provides the image to indexingprocess 64.

A single multi-page TIF file may include multiple documents. In such afile, each document is identified by a separate bar code, which may beprinted directly on the first page of the document or may be located ona separate coversheet immediately preceding the first page of thedocument. Accordingly, indexing process 64, responsively to theinformation provided by the bar codes, separates the file intoindividual document images for storage in database 48.

In the presently-described embodiment, indexing process 64 stores alldocuments to database 48 in PDF format. It should be understood,however, that documents could be stored in various other suitableformats. Upon receiving TIF files of scanned or faxed images, indexingprocessor 64 translates the TIF document images into PDF files.Similarly, if files uploaded from other sources are not in PDF format,indexing process 64 translates such files, provided the indexing processrecognizes the format of the received file. File translation processesshould be well understood and are, therefore, not described herein.

B. System Operation

Referring again to FIG. 3, a system administrator may communicate withserver 42 through an administrator workstation 50, either through adirect connection as shown in FIG. 3 or through an Internet connection.The system initially prompts the administrator for a username andpassword. Upon successfully providing this information, server 42presents the administrator with an options screen shown in FIG. 5. An“error log” button allows the administrator to view system errors loggedby server 42. An “indexing queues” button allows the administrator toview file queues in indexing process 64 in which the indexing process istranslating scanned TIF files into PDF format files. An “SQL Query Tool”button allows the administrator to create and execute database commandsagainst database 48. Buttons are also provided by which theadministrator may review company billing information and perform Website maintenance. For purposes of clarity, such system managementfunctionality is not discussed in detail herein but should be understoodby those skilled in this art.

A “Company Maintenance” button 72 presents a company list screen shownin FIG. 6. The company list screen includes a line for each cliententity (in the mortgage example, the lender, broker, etc.) registeredwith the primary system for storing and managing documents. To the leftof each company name are five icons that enable the administrator toview and update system settings for each company. If the administratoractivates an icon 74 for a listed company, the primary server 42 (FIG.3) presents a screen shown in FIG. 7 that lists all users authorized toaccess documents stored for the company. As shown in FIG. 7, the systemstores each user's first name, last name and a login name. A userlogging into the system presents a user name that is a combination ofits company name and the login name shown in FIG. 7. A User ID, whichthe system automatically creates when a user is added, is also listed,as is the user's email address. A “delete” icon 76 allows theadministrator to delete the user from access to the client's documents.An icon 78 presents a screen by which the administrator may reset theuser's password. In the presently-described embodiment, user informationis stored by SITE SERVER, available from MICROSOFT CORPORATION. SITESERVER is also responsible for authenticating all requests to the WebServer. For each user, the SITE SERVER database provides a GloballyUnique Identifier (GUID) as the User ID, which can be subsequently usedto store and retrieve information related to the user in the repositorydatabase. It should be understood, however, that the system could useany suitable user database and authentication sub-system, such as ActiveDirectory from MICROSOFT CORPORATION.

A “Create User” button 80 presents a screen shown in FIG. 8 throughwhich the administrator may create a new user. The screen provides entryblanks for the information shown in the screen of FIG. 7. If the userhas requested a specific password, the administrator may enter thepassword in the blank provided in FIG. 8. If not, the administrator maycause the system to randomly generate a password through activation of ascreen button 84. Activation of a “Create” button at the bottom of thescreen stores the user in the system database, and the user thereafterappears on the user screen shown in FIG. 7 for that client.

Returning to FIG. 7, activation of an icon 82 permits the administratorto change the information shown for that user in FIG. 7. The systempresents a screen similar to that shown in FIG. 8, except that thecurrent user information populates the property fields. After changingany information as desired, the administrator may activate an “update”button to modify the user information in the database and as shown onthe screen in FIG. 7.

Returning to FIG. 6, activation of a “company folder attributes” icon 86presents a screen shown in FIG. 9 through which the administrator maydefine attributes for all folders set up for the particular client. Inthe presently-described embodiment, a “folder” refers to a group ofdocument images relating to a single transaction, for example amortgage. Thus, a transaction party defines a folder in the system foreach transaction. A party may populate optional or required data fieldsto describe its folders that define its attributes, or data structure,for each folder stored in the database for the party.

A transaction party defines the attributes of its folders through theprimary system administrator, although it should be understood that thistask could also be effected by the transaction party at its workstationthrough screens provided by the client interface. Through the screenshown in FIG. 9, the administrator may review the attributes of theselected party's folders. In the presently-described embodiment, eachtransaction party has a single set of folder attributes. That is, whilethe party may establish multiple folders, each folder is defined by thesame parameter set. It should be understood, however, that the systemmay be configured to permit definition of multiple sets of folderattributes. In that case, the user selects a desired folder type whensearching for or opening folders.

An exemplary set of folder attributes for a mortgage transaction isillustrated in FIG. 9. The first two fields, folder creation date andfolder author, are system-maintained folder attributes and may not beedited. The remaining fields are populated as desired by the transactionparty. In this example, the additional fields are mortgage number,applicant first and last names, underwriter name, applicant state andapplication status. Through the administrator, the applicant may chooseany desired caption for each field and may define whether the field isrequired by checking a box in the “required” column in the field line.If a field is required, the system will require that a transaction partyenter this information before setting up a new folder in the database.If the party attempts to set up a folder without required information,the system prompts the party for the field data. If the “non-editable”box is activated for a given data field, the transaction party will beunable to edit data entered for that field in a given folder once thefolder is set up. Activation of the “PK” box for a given data fieldindicates that data entered in that field must be unique among allfolders for the transaction party. In the mortgage example discussedabove in which each folder represents a different mortgage, each foldermust have a unique number.

The system may support one or more look-up lists that may be provided tothe transaction party as the means by which to provide data for a givendata field. If it is desired to provide a look-up list for a given datafield, the administrator selects the desired list from a higher-orderlook-up list at the right hand column of FIG. 9. In the example shown inFIG. 9, a party setting up a mortgage folder may select the applicant'sstate from a look-up list of state postal codes. As should be apparent,the type and number of look-up lists provided as options in file set-upwill depend upon the type of transaction in which the folder will beused and may be defined as appropriate.

The system may support a plurality of pre-defined data field formatlines which a user may use to define a folder attribute. Each includesan ID number, a column description, a caption field, a type description,a look-up selection box and boxes for required, non-editable and PKdefinitions. Each format line may include a data entry field in adesired format, e.g. a desired number of integers or character spaces.When the administrator initially sets up a folder for a transactionparty, the screen shown in FIG. 9 includes only the first two datafields. The remaining data fields are provided in a separate screen (notshown), which may be provided in the same window adjacent or below thescreen shown in FIG. 9. To add an attribute to the folder definition,the administrator clicks on the desired data format line, and the systeminserts the line into the screen shown in FIG. 9. Un-selected data linesremain in the side area and are available if the user later wishes toedit its folder structure. To delete an attribute, the administratorclicks on an “X” icon to the left of the ID number for the desired dataline. After adding an attribute, the administrator fills in the datacaption field and checks the option boxes as appropriate. A “savechanges” button saves any changes made by the administrator to thefolder attributes in the database. A “reset all” button clears thecaption fields and option boxes for all attributes.

As described in more detail below, folder attributes and associatedvalues are displayed from various web pages. The sorting order in whichsystem presents the data fields to the client transaction party can varyfrom page to page. The system allows each party to define sorting ordersfor three different uses: search criteria; search results; and basicinformation. These three defined sorting orders are then used asappropriate by the different web pages to sort the folder attributesthat are presented.

Returning to FIG. 6, activation of an icon 88 for a given companydisplays a screen (not shown) listing each of the views defined for thatparty's folders. As indicated above, each folder defined by atransaction party corresponds to a given transaction. When theadministrator initially enters the transaction party in the database,the transaction party specifies one or more lists of document types itexpects to handle in its transactions. The administrator defines thesedocument type lists in the database in association with that party.Additionally, each party can define one or more folder views used toorganize a folder's contents when presenting the folder's information toa user. For each view, the party provides one or more desired documentgroups. From each document type list, the party specifies which documenttypes should be placed into which document type groups defined for eachview and in which order the document types should be sorted within therespective groups. All of this information is stored by theadministrator in the database in association with the transaction party.

As discussed above, a view may include one or more document groups andone or more document types for each group. Referring to FIG. 1, forexample, a mortgage broker may group documents into applicationdocuments, credit report documents, income documents and otherdocuments. Within the application group, the broker might define forms1008 and 1003 as document types.

From the view list screen (not shown), the administrator may activate abutton to create a new view for the folders of the selected transactionparty. A view creation screen (not shown) permits the administrator todefine document groups and types for a view.

If the administrator clicks on one of the views in the view list screen,the system presents a screen shown in FIG. 10 listing the selectedview's document groups and document type-to-group mappings. As should beunderstood by those in the mortgage industry, hard-copy documents aretypically maintained on the left or right side of a mortgage file.Documents are commonly referred to as either “left-side” or “right-side”documents, and the exemplary view shown in FIG. 10 defines two documentgroups according to this convention.

For example, from the view list screen (not shown), the administratormay click on one of the listed views to present a screen such as shownin FIG. 10. The screen lists each of the pre-defined groups and each ofthe document types defined for the group. In the illustrated example,all available document types are defined for the existing groups. Anyunused document types, however, would be listed in an area 90 to theright of the view description shown in FIG. 10. To add an unuseddocument type to the group for which it is defined, the administratorsimply clicks on the document type in area 90, and the system insertsthe document type at the bottom of the list for its document group. Todelete a document type currently listed for a group, the administratoractivates the “X” icon to the left of the document type, and the systemmoves the document type to area 90. The order of the document typeswithin a group may be changed through activation of the up and downarrows to the left of the document types in the list. Once theadministrator completes its changes to the view, the changes may besaved to the database through activation of a “save changes” button atthe bottom of FIG. 10. A “reset” button removes un-saved changes fromthe screen shown in FIG. 10.

From the view list screen, the administrator may define a new view byactivating an appropriate button on the screen to present a screensimilar to the screen shown in FIG. 10. All document types, however, arelisted in area 90, and the left-hand side of the screen contains onlythe document groups. The administrator may then define each group byclicking on the desired document types in area 90 and saving the newview to the database.

Returning to FIG. 6, an icon 92 presents a tool (not shown) by which theadministrator may view and amend drop-down lists for the folderattributes, as described above with respect to FIG. 9.

As discussed with respect to FIG. 7, multiple users may be defined foreach transaction party so that each user may have access to the party'sdocuments. Through the administrator, the transaction party defines theaccess rights applicable to each party in a security profile. Thetransaction party may define multiple profiles so that when the partyopens a new file, it may select a profile desired for that folder. Thus,a given user's access privileges may change from one folder to another.Additionally, the security profile defines the folder view that will bepresented to each user when that user opens any folder to which theprofile is assigned. Accordingly, depending on the security profile,different users may have different views of the same folder.

Returning to FIG. 6, activation of an icon 94 next to a giventransaction party's name presents a screen (not shown) listing each ofthe security profiles defined for that party. If the administratorclicks on one of the listed profiles, the system presents a screen shownin FIG. 11 that illustrates the access rights for the selected profile.As used herein, a security “role” refers to a group of users having thesame set of access rights within a given security profile. The profileshown in FIG. 11, for example, includes four roles. For each role, theadministrator may grant access rights by clicking one or more desiredboxes in the “Access Rights” column to place a check in the box or maydelete access rights by clicking on an existing check mark to therebyremove the mark. A “view” right provides the ability to view the folderand the documents contained by it, subject to document security profilesdiscussed below. A user may also be granted the right to delete thefolder. This deletes the folder definition in the database but does notdelete documents in the repository. The “add documents” right permitsthe user to add documents to the repository for the folder to which thesecurity profile applies. The “remove documents” right permits the userto remove documents from a folder. As discussed above, however, thisdoes not provide the user with the ability to delete documents from therepository. A document cannot be removed from the repository by anyparty. In the presently-described embodiment, the system automaticallydeletes a document when it is no longer associated with any folder.Alternatively, a document might remain in the repository for someadditional time period after the last reference to it has been deleted.

The “edit property” right permits the user to edit properties for afolder that are defined as editable. The “edit security” right gives theuser the ability to edit the folder security profile.

If any users defined in the list shown in FIG. 7 for the transactionparty are not currently assigned to a security role, such users arelisted under the “user” column of a box 96 to the right of the securityprofile view. In the right-hand column of box 96 adjacent each user nameis a list of all roles currently defined for the profile. To add theuser to a given role, the administrator clicks on the desired role inthe right-hand column of box 96 adjacent to desired user's name. Thesystem then inserts the user in the appropriate row in box 98. To removea user from a security role, the user clicks on the user name in therole. The system deletes the user from the role, and the user's name isreturned to box 96.

In addition to the users defined for the transaction party as shown inFIG. 7, box 96 also includes a “CREATOR” user. As indicated above, oneof the folder attributes is the user that creates the folder. This username is linked to the “CREATOR” user name in box 96. A user is grantedany permission that is either explicitly granted them through theaddition of their user name to role, or any permission that is grantedthe creator of a folder if that folder was created by the user. This maybe useful where it is desired to provide certain access rights to theCREATOR where the administrator does not know the CREATOR's identity.

To remove a role from the profile, the administrator clicks on an “X”icon in the left hand column of box 98 by the desired role. When a roleis deleted, all users in the role are returned to box 96. To insert anew role, the administrator activates the “add new role” button at thebottom of the screen, at which the system adds a new role to box 98. Theadministrator then enters a description for the role in the“description” column, defines access rights and adds users as describedabove.

As shown in FIG. 10, a folder view is also assigned to each role. Theadministrator defines, and may change, the folder view for each role.The view must be one of the views defined for the party as describedabove with respect to FIG. 10. Accordingly, the system presents documentimages to a user according to the view defined for that user by thesecurity profile assigned to the folder accessed by the user. Again,this means that a user may see different views in different folders andthat different users may see different views in the same folder.

The “save changes” button permits the administrator to save an editedsecurity profile to the database. Prior to saving the changes, theadministrator may remove edits by activating the “reset” button.

The administrator may also create a new security profile from theprofile list screen (not shown) described above. The screen includes a“name” field. The user enters a name for the profile and activates a“create” button, thereby causing the system to present a screen similarto the screen shown in FIG. 11. In the new screen, however, no roles aredefined, and all users are listed in box 96. The administrator defineroles for the new profile through the “add new role” button as describedabove.

Security profiles are also defined for documents. Through theadministrator, a transaction party may define a security profile that isstored in the database in association with that party. When one of theparty's users thereafter adds a document to the repository inassociation with one of the party's folders, the system activates apointer to the document security profile. Accordingly, when a userthereafter accesses one of the party's folders and then accesses one ofthe document images associated with the folder, the user's access rightsto the document are defined by both the folder security profile and thedocument security profile. Presently, the system defines a singledocument security profile for each folder that is initially assigned todocuments added to that folder. Thus, all documents in the folder areinitially subject to the same profile. It should be understood, however,that multiple document profiles may also be defined.

The security profile list screen (not shown) described above lists eachdocument security profile (if more than one) defined for the selectedparty. Selection of one of the listed document security profilespresents a screen similar to the folder security profile screen shown inFIG. 11, except that the document security profile defines differentaccess rights and does not define folder views. More specifically, thedocument security profile defines rights to remove documents, viewdocuments, edit document properties and edit the document securityprofile. As in folder security profiles, document removal refers to theability to eliminate access to the document from the folder in which theuser is operating at the time. In order to remove a document from afolder, the user must have document removal privileges in both thefolder and document security profiles. If the user is denied such rightsin either the folder security profile or document security profile, theuser is unable to remove the document from the folder. Similarly, theuser must be granted view access rights in both security profiles inorder to view a document image. The administrator may add and editdocument security profiles similarly to adding and editing foldersecurity profiles as discussed above.

Referring again to FIG. 3, when a transaction party user accesses hostsystem 40 from its work station 52 through Internet 46, client interfaceprocess 62 (FIG. 4) requests the user's user name and password. Eachuser name must be unique. In one embodiment, the user name is the user'sname as indicated in FIG. 7 in combination with the name of thetransaction party with which the user is associated. Passwords areassigned as described above. If the user provides a valid user name andpassword, the user interacts with the client interface to managedocument image views and folders through various web pages as describedherein.

The client interface first presents the transaction party user with afolder search screen, as shown in FIG. 12, that lists each folderattribute (FIG. 9) applicable for searching that transaction party'sfolders. The screen provides a field for each attribute, and the usermay provide entries to one or more fields as desired. To automaticallyenter the present date in the “Date Created” field, or to automaticallyenter the user's name in the “Created By” field, the user activatesbuttons provided to the right of those fields. Activation of the“search” button at the bottom of FIG. 12 presents a screen shown in FIG.13 listing each of the folders meeting the attribute limitation enteredby the user at FIG. 12. In the illustrated example, the search criteriawere for all folders in which the mortgage applicant state was Georgia.Responsively to the request, the client interface creates and executes aquery against database 48 (FIG. 3) and presents the screen shown in FIG.13 to the user at its work station. The column titles in FIG. 13represent the folder attributes defined for search results for thetransaction party to which the user is associated. The user may sort thesearch results using the attributes by clicking on the desired columnheading.

The present discussion assumes that the user has been granted access inthe security profiles to view the folder and documents and to take otheractions as described herein. In the event, however, that the userattempts to take an action for which the user does not have sufficientaccess rights, the host client interface notifies the user that there isinsufficient authority and does not execute the requested action.

“Open Folder,” “Edit Properties,” “Fax Coversheets” and “ScanCoversheets” icons provided to the left of each folder shown in FIG. 13permit the user to access the folder, edit its properties and obtain faxor scan coversheets by which the user may add additional documents tothe folder. Activation of the “Open Folder” icon 100 for a given folderproduces a folder view screen as shown in FIG. 14. The folder viewscreen includes a folder attributes box 102, a notes box 104 and adocument list box 106. Folder attributes box 102 displays the attributesestablished for the selected folder. If the user has sufficientauthority, the user may change the folder attributes by activation of an“edit” button at the top of box 106 through a screen shown at FIG. 15.An “edit attribute” tab on a tool bar 105 shown in FIG. 14 also directsthe user to the folder property screen shown in FIG. 15. This screenlists each attribute and, except for the creation date and creatorfields, provides an edit box through which the user may change theattribute information. The system automatically fills the “Date Created”and “Created By” fields when the user initially creates the folder. Thefolder property screen also permits the user to define the foldersecurity profile that is to be applied to the folder. A pull-down list108 includes the name of each folder security profile defined for thetransacting party to which the user is associated, as described abovewith respect to FIG. 11. The “update” button saves the changed folderproperties in the database, and a “reset” button removes any unwantedand unsaved edits from the current screen. To return to the folder viewscreen shown in FIG. 14, the user closes the window in which the folderproperties screen is displayed.

Notes box 104 permits the user to add comments relating to the folder.The box provides the date the note was entered, the user that enteredthe note, and a description heading. Activation of a view icon 110 opensa window that displays the text of the note. To add a new note, the useractivates an “add note” icon at the top of box 104, thereby opening awindow displaying a screen (not shown) having entry fields in which theuser may enter a note description and note text.

Document list box 106 displays each document image stored in therepository that is associated with the selected folder. For eachdocument, box 106 displays the document title, the document type, thedate the document was created, the party creating the document and anycomments attached to the document. The documents are grouped accordingto group headings 112. Documents are linked to document groups by theirdocument types. As described with respect to FIGS. 10 and 11, documenttypes are associated with document groups in a folder view which isassigned to the user in the selected folder by the folder securityprofile. Box 106 is the presentation of documents to the user as definedby the document view.

If the user has view access to a document, the user may view thedocument through a view icon 114. In response to activation of thisicon, the client interface creates and executes appropriate queriesagainst database 48 (FIG. 3) and opens a window for the user in which isdisplayed the document image in PDF format. The screen (not shown)includes a “properties” button that produces a document propertiesscreen shown in FIG. 16. Through this screen, the user may change thedocument's type or title and may provide comments for display indocument list box 106.

Returning to FIG. 14, a delete icon is provided at each document line bywhich the user may remove the document from the selected folder. Asdescribed above, this requires that both the folder and documentsecurity profiles provide removal rights to the user.

An “edit properties” icon 101 on each document line directs the userdirectly to the document properties screen shown in FIG. 16. Once theuser has reviewed a selected document, the user may activate a “mark asviewed” button in the document property screen, or in the document viewscreen (not shown), thereby activating a “has been viewed” icon at thedocument line in box 106.

As described in further detail below, documents submitted by a faxtransmission are not executed through a user login event. Accordingly,the indexing process initially marks each faxed document as beingnon-verified, and a “not verified” icon is displayed at the documentline in box 106 for any such document. In this case, the documentproperty screen (FIG. 16) for such a document displays “No” in the “HasBeen Verified” line, along with a “mark as verified” button (not shown).Activation of the button by the user removes the “not verified” iconfrom document list box 106.

Within a folder, a user may instruct the client interface to send anemail to the user's email address, or to other selected addresses, whenthe folder receives documents of a predefined type. To set suchnotifications in a folder, the user activates a “notifications” tab ontoolbar 105. In response, the client interface presents a notificationsscreen as shown in FIG. 17. The notification screen includes adescription line 116 in which the user may enter text to be included inthe email message. In a pull-down list 118, the user may select any ofthe email addresses for users associated with the same transactionparty, and/or the user may enter other email addresses at line 120. Theuser may select one or more document types that will trigger anotification in a box 122.

Thereafter, the client interface sends an email to each email addressselected or entered at lines 118 and/or 120 whenever a document of atype selected in box 122 is added to the folder. If the user designatesthe notification as a “single type” at line 124, the client interfacesends an email to the listed email addresses only when documents underall document types selected in box 122 have been added to the folder.This type of notification will only occur once, after the last of therequired document types is added to the folder. If the user selects the“recurrent” type, the client interface sends emails to the selectedaddresses any time a document under any of the selected document typesis added to the folder.

If the user selects a “Tardy Notification” box at line 124, andspecifies a date and time, the client interface will also send an emailto the defined email addresses if documents under all document typesselected in box 122 have not been added to the folder by the date andtime specified in line 126. In the present embodiment, the clientinterface sends tardy notifications only if the “single” type isselected at 124.

From toolbar 105, activation of a “faxing” tab causes the clientinterface to respond with a fax coversheet screen as shown in FIG. 18. Abox 128 lists each document type defined for the folder. If the userselects one or more document type and executes a “submit” button at thebottom of the screen, the client interface generates a fax coversheet,such as shown in FIG. 19, for each document type. Each fax coversheetcontains one or more barcodes that provide the information required tocategorize and place the document in the repository, which at a minimumincludes the document type and destination folder identifier.

Referring also to FIGS. 3 and 4, the user places the appropriate faxcoversheet (i.e. by document type) in front of each document the userwishes to submit to the repository for the folder. Each document may beone or more pages in length. The user then sends the fax coversheet anddocument through the user's fax machine 56 by a dial-up connection tohost fax server 59. The fax number for server 59 may be printed on thefax coversheet. In the presently preferred embodiment, all coversheetbarcodes are defined by “3 of 9” (or code 39) barcoding.

Fax server code 66 receives the fax image and downloads the resultingTIF file directly to indexing process 64. Indexing process 64 scans theTIF image for the barcodes, extracting indexing information from theavailable barcodes. Using the barcode data, the indexing processseparates the TIF image into one or more documents, which it thenconverts to PDF files, and stores the image in database 48 inassociation with the document type, folder ID and any other associateddata extracted from the fax coversheet.

Referring again to the fax coversheet request screen in FIG. 18,activation of a “file completed notification” selection box in a box 132causes the client interface to generate a fax coversheet that allows theuser to trigger an email to a designated email recipient for the folder.In initially setting up a transaction party, the administrator maydefine an email address provided by the transaction party to which “FileCompleted Notification” emails are to be sent. This may be useful, forexample, when a user preparing documents for a file completes thedocumentation for a file and wishes to notify the transaction party'semail recipient that the file is complete. To do this, the user selectsthe “File Completed Notification” box and executes the “submit” buttonat the bottom of the screen in FIG. 18. In response, the clientinterface generates a fax coversheet similar to the coversheet shown inFIG. 19. The coversheet contains barcodes that indicate the relatedfolder ID and the notification action to be taken. The user then faxesthe coversheet alone to fax server 59 (FIGS. 3 and 4). Upon receivingthe resulting TIF file from the fax server code, the indexing processreads the barcode data and causes the primary server software to send anemail through the Internet 46 to the email recipient address associatedwith the party that created the folder specified by the folder IDindicated in the barcodes.

A user may also scan documents to create document images for storage inthe repository. Referring again to FIG. 14, activation of a “scanning”tab on toolbar 105 causes the client interface to generate a scanningbatch coversheet such as shown in FIG. 20, which contains one or morebarcodes that indicate the ID of the associated folder.

The scanning batch coversheet may be used to cover multiple documents ofdifferent document types. Each document has its own scanning coversheet,referred to herein as a “document separator coversheet.” To generate aseparator coversheet in the mortgage example discussed herein, the useractivates a “Mortgage Documents” button 138 in the scanning batchcoversheet shown in FIG. 20. In response, the client interface generatesa scanning coversheet document type screen as show in FIG. 21. Similarlyto the fax coversheet selection page, the user may select one or moredocument types from a list of document types defined for the folderprovided in a box 140. Activation of a “submit” button causes the clientinterface to generate a document separator coversheet, as shown in FIG.22, for each selected document type. Each coversheet contains one ormore barcodes 144 that indicate the associated document type.

Returning to FIG. 20, activation of a “File Completed Notification”button in the scanning batch coversheet screen causes the clientinterface to generate a “File Completed Notification” coversheet, whichfunctions in the same way as previously described for faxing. The usermay fax this coversheet to the host fax server or may include the sheetin a scan.

Returning to the scanning coversheets shown in FIGS. 20 and 22, andreferring also to FIGS. 3 and 4, the user places an appropriate (i.e.according to document type) document separator coversheet over eachdocument it wishes to scan. The user then feeds the scanning batchcoversheet, followed by each document/coversheet combination, into theuser's scanner 58. A scan program module at user workstation 52interfaces scanner 58 and the user's workstation 52. The scan programcode controls scanner 58 and reviews each scanned page for bar codes.

The user activates the scan program module, written in a combination ofVISUAL BASIC and C++, at its workstation 52 prior to scanning documents.Upon activation, the scan program connects to the host Web Serverthrough the user's Web browser and requests the user and folderproperties from the host system. The host system first requires a userlogin, and the scan program therefore prompts the user for its user nameand password for the host client interface. If the user successfullyenters this information, the scan program retrieves any requiredconfiguration information, such as folder properties, stored by the hostsystem and used by the scan program module.

The scan program code permits the user to scan images without a scanningcoversheet. To do so, the user selects the “file” pull-down list from amain scan program page (FIG. 23) presented by the scan program atworkstation 52 and selects a “Select Destination Folder” from theresulting pull-down menu. This causes the scan program code to produce afolder search screen at the user's workstation, as shown in FIG. 24.Upon filling in desired search criteria and activating a “search” buttonon the screen, the scan program code connects to the client interface atthe host system and provides the search criteria to the clientinterface. The client interface executes appropriate queries againstdatabase 48 and returns a list of folders that meet the search criteriafor the transaction party with which the user is associated, as shown inFIG. 25.

Selection of one of the folders from the screen loads the folderattribute information in a “Destination Folder” box 150 in the main scanprogram screen shown in FIG. 23. The user then enters the document typefrom a pull-down box that lists all document types for the document typeidentified in box 150. The user may also define a document title andinsert comments. Activation of the “scan” button at the top of thescreen drops a pull-down list from which the user activates the user'sscanner 58 (FIGS. 3 and 4). The user then feeds the desired documentinto the scanner, and the scan program stores the resulting TIF file inassociation with the folder ID from box 150, the document type enteredby the user, the user's User ID, the date and time of scanning, and thedocument title and comments, if any, entered by the user. At the end ofthe scan, the scanned document is displayed in a window 152. Thisprocedure may be repeated within the same destination folder. For eachdocument, the user selects a document type, optionally enters a titleand comments, and executes the “scan” button in the scanning screen. Thescan program accumulates scanned document images under the destinationfolder ID.

A “new document” option in the “scan” pull-down list allows the user toidentify another document type, title and comments and execute asubsequent scan. Thus, the user may add documents of different types tothe scan file for the destination folder. An “append page” option underthe “scan” pull-down allows the user to scan a page for addition to theend of an existing scan. An “insert page” option allows the user to scanone or more new pages and add the new pages before the page currentlyviewed in box 152. A “delete page” option allows the user to delete apage currently viewed in box 152.

Having searched for and selected a destination folder for scanneddocuments, so that the system displays the selected destination folderin box 150, the user may elect to use document separator coversheets inassociation with each document, rather than entering the document typefrom the pull-down list shown in FIG. 23. In this case, the user selectsthe box shown in FIG. 23 indicating that the scanned documents containcoversheets. If the user has selected a destination folder, a batchcoversheet is unnecessary, and the scan program expects only documentseparator coversheets. If the user has not selected a destinationfolder, so that box 150 is empty, the scan program looks both for abatch coversheet and document separator coversheets. In either case, theuser may enter a title and comments for each document.

If the user selects the coversheet option, scanning proceeds in the samemanner Assuming both batch and document separator coversheets are used,the user selects the “scan” pull-down list and selects the scanexecution option. The program receives and stores the scanned image inassociation with an identifier indicating that the image is expected tocontain batch and separator coversheet barcodes. At the end of the scan,the scanned program presents a screen (not shown) prompting the userwhether the user wishes to scan additional pages to the existing file,to store the image, or to review the image. If the user elects to storethe image, the TIF image is stored in association with the coversheetidentifier, and the user may execute additional scans from the “scan”pull-down list at the main scan screen. For each subsequent scan to thesame scan file, the scan program would expect only a document separatorcoversheet, not a batch coversheet.

If the user selects the coversheet option and defines a destinationfolder in box 150, the scan program stores the resulting TIF images inassociation with the folder ID and an identifier indicating thatdocument separator barcodes, but not batch barcodes, are present in theimages.

To upload a scanned file at the end of a scan procedure, the userselects the “file” pull-down list in the screen shown in FIG. 23 andselects a “Submit Current Document” option. The scan program contactsthe host system Web server through the user workstation Web browser andthe Internet and uploads the TIF images in the scan file, along with thefolder ID, the User ID, and the document type for each documentcontained in the TIF image. The host browser hands the received scanfile to the indexing process, which translate the TIF images into PDFformat and stores the images in the host system database with theassociated information.

In addition to the fax and scan options, the user may upload apreviously-stored electronic image to the repository at the host system.Referring again to FIG. 14, activation of an “upload document” tab attoolbar 105 causes the client interface to present the user with anupload screen as shown in FIG. 26. The screen includes a pull-down listpopulated by the document types defined for the folder. The user maydefine a title and comments to associate with the image document.

The screen includes an entry line for the file directory address atwhich the image file is located. A “browse” button 154 opens a WINDOWSEXPLORER window at the client workstation through which the user mayfind the desired document image file stored on the user's local ornetwork drives. Upon selection of the desired image file in the window,code located at the client workstation inserts the appropriate fileaddress in the address line. Activation of an “upload” button as shownin FIG. 26 causes the client-side code to contact the host system Webserver and upload the desired image file, along with the selecteddocument type, title, comments, folder ID, User ID, and document type.

The upload screen in FIG. 26 includes a box by which the user mayindicate whether the image file contains barcode coversheets. This maybe true, for example, if the stored document image was faxed or scannedwith barcode coversheets as described above. Because the coversheets areassumed to contain document types, activation of this box eliminates thedocument type field from the screen. Since the barcodes do notnecessarily include a folder ID, the folder ID field remains If theimage barcode contains a folder ID, the barcode folder ID controls.

If the upload file contains barcodes, the indexing process reads thebarcodes to determine the folder ID, User ID, and document type. If theupload file contains no barcodes, this information is provided in dataassociated with the image files. The indexing process detects the imagefile format and, if possible, translates the image into PDF format. Theprogram then stores the images in association with the folder, User ID,document type and, if provided, title and comments.

Referring again to FIG. 14, an “email link” tab on toolbar 105 causesthe client-side to generate from the user's web browser an e-mailenclosing a link to the page from which the “e-mail link” tab wasactivated. The user enters a desired e-mail address in the e-mail andsends the email to the desired party. Upon opening the e-mail, thereceiving party may enter the linked page by activating the e-mail link.Before presenting the receiving party with the web page, however, thehost system prompts the receiving party for a user name and password forthe applicable folder. A user may execute the e-mail link option, forexample, while reviewing a document in order to share the document withanother user defined under the folder.

To increase reviewing speed, the user may wish to download electroniccopies of document images to its local drive, rather than review eachimage over an Internet connection. To do this, and again referring toFIG. 14, the user activates a “download docs” tab on toolbar 105. Inresponse, the client interface provides a folder download screen asshown in FIG. 27. The screen lists each image document stored in therepository for the folder, again grouped by document group and documenttype as defined by the folder's security profile. Using check boxes atthe left of the document image lines, the user may select those documentimages it wishes to download.

The html supporting the page shown in FIG. 27 includes embedded code (anActiveX component, compiled from VISUAL BASIC code) that establishes acommunication with the host web server through the user's workstationWeb server and the Internet and that downloads the requested documentimages from the host database to temporary storage at the user'sworkstation. After selecting the desired document images and executing a“download” button at the bottom of the screen shown in FIG. 27, theselected documents are downloaded and stored on the user's workstation.

Upon completion of the file download, the client interface returns theuser to the folder view screen shown in FIG. 14. Thereafter, when theuser accesses a view of the document through the folder view screen, thedocument image is retrieved from the user's local temporary storage.When the user ends its document management session, the embedded codedeletes the downloaded document images from the user's storage.Alternatively, it should be understood that the system may leave thedownloaded image files in the user's memory.

Returning to the folder search results screen shown in FIG. 13, the usermay define a new folder by activating a “create a new folder” tab at atoolbar 107. This causes the client interface to present a foldercreation screen as shown in FIG. 28. The upper part of this screen issimilar to the folder attributes edit screen shown in FIG. 12, exceptthat the creation date and creator fields are omitted because the systemautomatically populates these fields upon creation of the new folder.Otherwise, the user may populate the folder attribute fields as desired.The “status” pull-down list in the present mortgage example allows theuser to select a designation indicating that the mortgage to which thefolder corresponds has been approved, declined, is pending, or is inunderwriting.

At the bottom of the folder creation screen, a pull-down box under“Folder Configuration” allows the user to select one of the foldersecurity profiles defined for the particular folder. As described above,this defines the folder security profile that will be applied to thefolder, the document type list that will be used by the folder, and thedocument security profile that will be initially applied to documentsthat are subsequently added to the new folder. Provided all requiredinformation is entered in the folder creation screen, activation of the“create” button at the bottom of the screen saves the folder to thesystem database.

Activation of a “User Profile” tab on toolbar 107 causes the clientinterface to generate a user profile screen as shown in FIG. 29. Thescreen automatically displays the user's username and User ID, which theuser may not edit. Provided the user has sufficient authority, however,the user may change its first and last name, e-mail address andpassword.

As indicated above, two different parties may share documents with eachother. That is, the parties may establish a relationship in the systemwhereby one party gains access to documents in the repository to whichthe other party has access and/or may have access in the future. Whenone transaction party (hereafter the “sharing” party) desires to sharedocuments from one of its folders with another transaction party(hereafter the “receiving” party), a user from the sharing party selectsa folder and activates a link (not shown) from the resulting folder viewpage (FIG. 14) that presents the user with a list of other transactionparties from which the user may select the receiving party. Once theuser selects the receiving party, the system presents a screen fromwhich the user may select a receiving party user to whom the system willnotify that a share has been initiated. As part of a party's set-up inthe system, the party identifies one of its users as a default recipientfor such notifications and may identify other users that may substitutefor the default. If such alternates are provided, the sharing party usermay select one from the screen.

While the present embodiment is described in terms of a sharing partydefining a share (as used herein, the term “share” refers to theestablishment of a relationship by which one party grants documentaccess to another party) for one receiving party at a time, it should beunderstood that the system may be configured so that the sharing usermay select multiple receiving parties from the receiving party selectionscreen. In that event, the user will select a notification recipient foreach receiving party, and the system database stores multiple shares—onefor each receiving party.

After selecting the notification recipient, the sharing user may chooseto share specific documents in its folder and/or to automatically sharefolder documents within one or more specified document types. The lattermethod is referred to herein as a “recurrent” share. In a screen similarto the download screen shown in FIG. 27, the system presents the userwith a list of documents currently existing in its party's folder. Toshare specific documents, the user selects one or more documents bychecking boxes beside the respective documents in the screen. The usermay instead or additionally indicate that a recurrent share beestablished by checking a “recurrent share” box, in which case thesystem presents the user with a list of document types used by theapplicable folder. Responsively to the parties, the administrator mayhave pre-defined in the system a global list of document types for arecurrent share. In such a case, the user may simply choose a globallist to automatically define the document types. Alternatively, the usermay define the document types for the recurrent share on a case-by-casebasis. Here, the user selects one or more document types to be includedin the recurrent share by checking boxes in the screen by the respectivetypes.

Having identified the source folder, the receiving party and thedocuments and/or document types to be shared, the user executes theshare by activating a “submit” button in either the document list ordocument type screens. The system then notifies the receiving party ofthe share, for example by sending an email to the specified receivingparty user or presenting that user with a pop up notification screenwhen the receiving party user next logs into the system.

The receiving party is then responsible for accepting the share and forspecifying the destination folder for the shared documents. Uponactivation of a “share” tab, the system presents the receiving partyuser with a screen listing all shares that have been initiated to thereceiving party. The user then selects a share it desires to accept byactivating a check box by the desired share.

Shared documents are applied to an existing or new folder belonging tothe receiving party. Accordingly, the system allows the receiving partyto establish a map between the document types of the sharing party'sfolder to the document types of its folder. Where the receiving partysets up a new folder, the system also maps the attributes of the sharingparty's folder to the new folder, thereby avoiding the need to manuallyenter attribute data. In a presently preferred embodiment, the systemadministrator defines attribute maps in the data hierarchy describedbelow responsively to the parties.

When the receiving party user selects a share from the share listscreen, the system presents a list of the receiving party's folders. Ifthe user selects one of these folders, the system applies the shareddocuments to the selected folder. If the user selects a “new folder”icon in this screen, however, the system first presents a screen similarto the folder attributes screen shown in FIG. 15, in which the attributefields are populated by the attributes in the sharing party's folder asdefined by the attribute map. In the mortgage example, the map mayautomatically populate fields applicable to all parties, such asmortgage number, applicant information and date. The user may change anydesired fields and may fill in any unmapped fields.

In order for the system to share a document from one folder to another,the document type map correlates the document type under which thedocument is assigned in the source folder to a document type to whichthe document should be applied in the destination folder. Although theparties involved in each sharing transaction may provide thisinformation as needed, the system may also store default mappings (whichare predefined by the administrator responsively to the parties) bywhich the system facilitates future sharing transactions between thesame parties.

When the receiving party user selects an existing or new folder to whichto apply the shared documents, the system first presents a screenlisting any specifically shared documents. The screen shows the sourcefolder's document types on one side and the receiving folder's documenttypes on the other. On the source side, the screen lists each shareddocument under its associated document type. On the receiver side, thesystem lists the shared documents under the receiving document typesaccording to the default map. The receiving party user may, however,change the mapping. To move a document from one document type in thereceiving folder to another, the user clicks on a box beside the desireddocument, thereby presenting a drop-down list of all document types inthe receiving folder. Selecting a type in the list moves the document tothe new type.

If no default mapping exists, the screen's receiver side lists theshared documents without association to document types. The user thenactivates a box beside each document and selects a desired documenttype.

To accept the document mapping, the user activates an “accept” button onthe document share screen. If the user activates this button when thereis also a recurrent share, or if there is only a recurrent share whenthe user selects a receiving folder, the system presents a screen thatpresents a document type mapping between the source (sharing) folder andthe receiving folder. The screen lists the sharing folder's documenttypes on one side and the receiving folder's document types on the otherside. The sharing types are grouped beside the receiving types to whichthey apply, and multiple sharing types may map to the same receivingtype. The user may change the map. To move a sharing type from onereceiving type to another, the user clicks on a box beside the desiredsharing type, thereby presenting a drop-down list of all document typesin the receiving folder. Selecting a type in the list moves the sharingtype to the new receiving type. Upon activating an “accept” button onthis screen, the system saves the new map.

Once the receiving party accepts the share, the system applies anyspecifically shared documents to the receiving party's folder. If thereis a recurrent share, the system applies to the receiving party's folderany documents of the selected type(s) that then exist in the sharingparty's folder or that are thereafter added to the sharing party'sfolder. More specifically, the system thereafter monitors the sharingparty's folder for the addition of documents of a type corresponding toone of the types associated with the recurrent share and automaticallyshares any such documents to the receiving party's folder.

The sharing party may terminate or disable a share at any point, but anydocuments already shared to the receiving party's folder remainavailable to the receiving party.

C. Data Hierarchy

FIG. 30 describes a data hierarchy for folder, document and systemconfiguration information and relationships stored at the host systemdatabase. Within FIG. 30, the following conventions are used to describetable columns and relationships. A line drawn between two tablesindicates a foreign key relationship, with an arrow indicating theparent table. For example, the line drawn between tables 158 and 160,with the arrow pointing to table 158, indicates that primary key-foreignkey relationship exists between the two tables, that table 158 is theparent table of this relationship, and that table 160 is the child. Eachtable column may denote additional properties. The letters “PK” next toa column indicate that the column is part of the primary key for thattable. The letters “FK” next to a column indicate that it is the childof a primary key-foreign key relationship. The letter “U” next to acolumn indicates that it is part of a unique key constraint. The FK andUK symbols also contain a number qualifier, such as “FK1” and “FK2,”which discern between multiple keys of the same type within the sametable.

It should also be noted that description of the database tables uses theterm “company” to identify a transaction party. As such, eachtransaction party is assigned a unique company ID in the system, whichis subsequently used to identify the data associated with that party.

Referring to table 162, FOLDER_ATTRIBUTES, each of the available folderattributes defined by the system are assigned a unique ATTRIBUTE_ID. Theinformation in this table describes the columns that are present in theFOLDERS table described below and that can be used by companies todefine which attributes are used to define their folders. For eachattribute entry in this table, the following information is provided.COLUMN_NAME indicates the name of the attribute's corresponding columnin the FOLDERS table. DATA_TYPE indicates the column's data type (i.e.,numeric or text). LENGTH indicates the maximum length of a value thatcan be stored for the attribute. IS_SYSTEM is a flag that indicates ifthe value of the attribute is maintained by the system. DEFAULT_CAPTIONindicates the default caption that should be used when displaying theattribute to a user. NONEDITABLE indicates if the attribute is noteditable. IS_REQUIRED indicates if the attribute requires a value.

Referring to table 156, COMPANY_FOLDER_ATTRIBUTES, the systemadministrator may associate to each company any of the non-systemattributes enumerated in table 162 above. In this way, each company isprovided some flexibility in how they wish to describe their folders.For each attribute, the company may also wish to override some of thesystem settings for a particular attribute. Specifically, using theCAPTION column, a company can override the default caption displayed foran attribute. Using the NONEDITABLE column, a company can also make anattribute otherwise designated as editable by the system non-editablefor their folders. Likewise, using the REQUIRED column, a company canmake an attribute otherwise not designated as required by the systemrequired for their folders. Lastly, using the LOOKUP_LIST_ID column, acompany may wish to associate an attribute with a lookup list of values,as described below, to control the available values a user can assign tothat attribute.

As described previously, a company may establish a list of specificvalues that can be assigned to one or more folder attributes. Assigninga lookup list to an attribute facilitates easier data entry by the userand provides a way to control or limit the values entered. Each list oflookup values is first defined in table 158, LOOKUP_LISTS. Each list isassigned a unique identifier which is stored LOOKUP_LIST_ID. TheCOMPANY_ID column indicates the company that defined the list.DESCRIPTION provides a textual description of the list. SYSTEM indicatesif the list is defined by the system and, therefore, available for usewith any company's attributes. Non-system lists can only be applied toattributes defined by the same company that defined the list. Lastly,the SORTBY column indicates the preferred method used to the sort thelist members as described below. The sorting method may specify that themembers are sorted alphabetically using their descriptions,alphabetically by their values, or by a custom sort order specified foreach member

Referring to table 160, LOOKUP_LIST_MEMBERS, each lookup list willcontain one or more members. For each member, the company must provide adescription (DESCRIPTION) and may optionally provide a value (VALUE)that, if present, is used in place of description when storing a valuefor the attribute. If desired, the SORT_ORDER column may be used todefine how the members of the lookup list are sorted when displayed to auser. The STATUS column indicates if the lookup list member should bemade available to the user when assigning attribute values. This STATUSoption allows for a certain lookup list member to effectively beretired, meaning that it can not be used when assigning new values to afolder attribute but that it is still valid for folder attributes whichhad previously been assigned its value.

As described previously, each company can specify which attributesshould be used to uniquely identify a folder, following the same conceptas a primary key in a database. For each attribute that is designated aspart of the unique key for a company's folder, an entry is made in table164, COMPANY_PK_ATTRIBUTES.

Referring to table 166, COMPANY_ATTRIBUTE_SETS, each company can definesubsets of its available attributes that can subsequently be used by Webpages to filter and or sort attributes specifically for certainfunctions. In the presently-described embodiment, the system definesthree such subsets: attributes made available for search criteria,attributes used to display search results, and attributes used todescribe a folder in basic detail rather than full detail. For eachattribute that is a member of an attribute subset, an entry is made inthis table. The COMPANY_ID column indicates the company with which thecorresponding attribute set is associated. The SET_TYPE column indicatesthe attribute set in which the attribute is a member. The ATTRIBUTE_IDcolumn contains the identifier of the attribute being included in theset. The DISPLAY_ORDER column indicates the order in which the attributewill be sorted within the attribute set.

Referring to a table 176, each folder defined in the database isassigned a unique folder ID number which is stored in the FOLDER_IDcolumn The COMPANY_ID identifies the company that created the folder.The DATE_CREATED column indicates the date and time that the folder wascreated. The CREATED_BY_USER_ID column stores the identifier of theindividual user that created the folder. The SECURITY_ID columnindicates the folder security profile, as described below, that is to beapplied to the folder. The NEW_DOCUMENT_DEFAULT_SECURITY_ID indicatesthe document security profile, as described below, that is to beinitially applied to documents added to folder. The DOC_TYPE_LIST_IDcolumn indicates the document type list, as described below, that isused to classify documents associated with the folder. The remainingcolumns are used to store values for the non-system folder attributesdescribed above (table 156) that are made available to each company.

Referring to table 168, DOCUMENTS, each document added to the repositoryis associated with an entry in the database. Each document is assigned aunique DOCUMENT_ID by the system, which is stored in the DOCUMENT_IDcolumn. The DATE_CREATED column indicates the date and time the documentwas added to the repository. The CREATED_BY column indicates the userthat added the document to the repository. The SOURCE column indicatesthe mechanism by which the document was added to the repository, forexample by fax, scan or upload. The LOCATION column is used to indicatewhere the document image is located, which is used to subsequentlyretrieve the document as necessary.

Referring to table 172, FOLDER_DOCUMENTS, each document may beassociated with one or more folders. As such, for each documentassociated with a folder, an entry is made in this table. The FOLDER_IDcolumn identifies the folder with which the document is associated. TheDOCUMENT_ID column identifies the document being associated. TheDOC_TYPE column identifies the document's classification within thefolder, and must be a valid member of the document type list associatedwith the folder. The TITLE column optionally indicates a title for thedocument. The COMMENTS column optionally indicates comments for thedocument. The SECURITY_ID column indicates the document security profilethat is to be applied to the document. The ADDED_BY_USER_ID columnindicates the individual user that associated the document with thefolder. The ADDED_DATE indicates the date and time at which the documentwas associated with the folder. The VERIFIED_STATUS indicates whetherthe document has not been verified, as described previously in thediscussion of the folder view web page (FIG. 14).

Each user has the ability to track which documents it has viewed in eachfolder. Each time a user indicates to the system that it has viewed adocument, an entry is made in table 170, USER_DOCUMENT_TRACKING. TheFOLDER_ID column identifies the folder from which the viewed documentwas accessed. The DOCUMENT_ID column identifies the document that wasviewed. The USER_ID column identifies the user that is indicating thedocument has been viewed.

Referring to table 174, NEW_FOLDER_CONFIGURATIONS, when a folder iscreated, the system applies certain default characteristics to the newfolder. Each company can define one or more configurations from which auser can select when creating a new folder. Each configuration isrepresented by an entry in this table and is uniquely identified by anID stored in the CONFIGURATION_ID column. The COMPANY_ID columnidentifies the company with which the configuration is associated. TheDESCRIPTION column stores a textual description of the configurationthat allows a user to recognize its characteristics. The SECURITY_IDcolumn indicates the folder security profile id that should be initiallyapplied to the folder and stored in the SECURITY_ID column of theFOLDERS table. The NEW_DOC_SECURITY_ID indicates the value that shouldbe stored in the NEW DOCUMENT_DEFAULT_SECURITY_ID column of the FOLDERStable. The DOC_TYPE_LIST_ID indicates the document type list that willbe used for the folder and is the value stored in the DOC_TYPE_LIST_IDcolumn of the FOLDERS table. The IS_DEFAULT column indicates whichconfiguration is the default for a company.

Referring to table 178, FOLDER_NOTES, and as described previously, auser is able to create and associate notes with a folder. Each note isstored as an entry in this table and is assigned a unique ID which isstored in the NOTE_ID column. The FOLDER_ID column indicates the folderwith which the note is associated. The DATE_CREATED column stores thedate and time at which the note was created. The USER_NAME column storesthe name of the user who created the note. The DESCRIPTION column storesthe note description or subject line. The CONTENT column stores the bodyof the note.

Referring to table 186, FOLDERS_SECURITY_PROFILES, each company canestablish one or more folder security profiles that describe user-levelaccess to a folder. For each profile defined by each company, an entryis made in this table, and a unique identifier is assigned and stored inthe SECURITY_ID column. The COMPANY_ID column indicates the companyassociated with the profile. The DESCRIPTION contains a textualdescription of the profile that enables a user to more readily recognizeits characteristics.

Referring to table 188, FOLDERS_SECURITY_PROFILES_ACL, each profilecomprises one or more user roles, each of which is assigned permissions.Each role defined for profile is entered in this table and assigned anidentifier unique to the profile. The SECURITY_ID indicates the profilewith which the role is associated. The ROLE_ID contains the uniqueidentifier of the role in the profile. The ROLE_DESCRIPTION contains atextual description of the role that enables a user to more readilyrecognize its characteristics. The VIEW_ID column indicates which view,as described below, should be used to present a folder's contents whendisplaying a folder with the SECURITY_ID to a user who is a member ofthe role. The CAN_VIEW column indicates if members of the role can viewa folder with the associated SECURITY_ID. Likewise, the CAN_DELETEcolumn indicates if members of the role can delete the folder; theCAN_ADD_DOCS column indicates if members of the role can associate newdocuments with the folder; the CAN_REMOVE_DOCS attribute indicates ifmembers of the role can remove associations between documents and thefolder; the CAN_EDIT_PROPERTIES indicates if members of the role canedit the attribute values of the folder, and the CAN_EDIT_SECURITYdetermines if members of the role can change the security profileassociated with the folder.

Referring to table 190, FOLDERS_SECURITY_PROFILES_ROLE_MEMBERS, eachuser that will be granted any level of access to a folder must first beassigned to one of the roles defined by the security profile applied tothat folder. For each such user, an entry must be made in this table.The SECURITY_ID and ROLE_ID columns indicate the profile and role withwhich the user will be associated. The USER_ID column indicates the userthat is being associated.

Referring to table 180, DOCUMENTS_SECURITY_PROFILES, each company canestablish one or more document security profiles that describeuser-level access to a document. For each profile defined by eachcompany, an entry is made in this table, and a unique identifier isassigned and stored in the SECURITY_ID column. The COMPANY_ID columnindicates the company associated with the profile. The DESCRIPTIONcontains a textual description of the profile that enables a user tomore readily recognize its characteristics.

Referring to table 182, DOCUMENTS_SECURITY_PROFILES_ACLS, each profilecomprises one or more user roles, each of which is assigned permissions.Each role defined for profile is entered in this table and assigned anidentifier that is unique to the profile. The SECURITY_ID indicates theprofile with which the role is associated. The ROLE_ID contains theunique identifier of the role in the profile. The ROLE_DESCRIPTIONcontains a textual description of the role that enables a user to morereadily recognize its characteristics. The CAN_VIEW column indicates ifmembers of the role can view a document with the associated SECURITY_ID.Likewise, the CAN_DELETE column indicates if members of the role candelete the document; the CAN_EDIT_PROPERTIES indicates if members of therole can edit the attribute values of the document, and theCAN_EDIT_SECURITY determines if members of the role can change thesecurity profile that is associated with the document.

Referring to table 184, DOCUMENTS_SECURITY_PROFILES_ROLE_MEMBERS, eachuser that will be granted any level of access to a document must firstbe assigned to one of the roles defined by the security profile appliedto that document. For each such user, an entry must be made in thistable. The SECURITY_ID and ROLE_ID columns indicate the profile and rolewith which the user will be associated. The USER_ID column indicates theuser that is being associated.

Referring to table 192, FOLDER_VIEWS, each company can establish one ormore views, which describe how the contents of a folder are presented tothe user. For each view defined, the system assigns a unique identifier,and an entry is made in this table storing the identifier in the VIEW_IDcolumn. The COMPANY_ID indicates the company with which the view isassociated. The DESCRIPTION column contains a textual description of theview definition that enables a user to more readily recognize itscharacteristics.

Referring to table 194, FOLDER_VIEW_GROUPS, within each view definition,one or more document type groups can be defined. For each group definedin a view, an entry is made in this table. The VIEW_ID column indicatesthe view to which the group applies. The GROUP_NUMBER contains anidentifier for the group that is unique within the view. The DESCRIPTIONcolumn contains a textual description of the group.

Referring to table 196, FOLDER_VIEW_DOCTYPE_TO_GROUP_MAP, for eachdocument that appears in a view, its corresponding document type must bemapped to one of the groups in a view. It should be noted that a singleview can be used to display the contents of folders that use differentdocument type lists. For each document type and its respective documenttype list that should be shown in a view group, an entry will be made intable 196. The VIEW_ID indicates the view in which the document typewill appear. The DOC_TYPE_LIST_ID column indicates the document typelist in which the document type is a member. The DOC_TYPE columnindicates the document type that is being associated with a view group.The GROUP_NUMBER column indicates the group with which the document typeis being associated. The SORT_ORDER column indicates how the documenttype should be sorted within the group.

As described previously, a company establishes one or more lists ofdocument types that describe the types of documents typicallyencountered by that company. Each folder is associated with one of thecompany's document type lists. Each list defined by a company is storedas an entry in table 198, DOC_TYPE_Each list is assigned a uniqueidentifier which is stored LIST_ID. The COMPANY_ID column indicates thecompany that defined the list. DESCRIPTION provides a textualdescription of the list.

Referring to table 200, DOCTYPE_LIST_MEMBERS, each document type listcontains one or more members. For each member, an entry is made in thistable. The system assigns an identifier that is unique within the listand is stored in the DOC_TYPE column. The LIST_ID column indicates thelist in which the document type is a member. The DESCRIPTION columnstores a description of the document type as provided by the company.The SORT_ORDER column optionally contains the order in which thedocument type is sorted within the list.

Each time a user defines a document type notification, as describedpreviously, the system makes an entry in table 214,FILE_ADDED_NOTIFICATIONS. For each notification established, the systemgenerates a unique identifier which is stored in the NOTIFICATION_IDcolumn. The DESCRIPTION column allows the user to optionally provide adescription for the notification. The USER_ID column indicates the userthat established the notification. The FOLDER_ID column indicates thefolder that is associated with the notification. The EMAIL_ADDRESSEScolumn contains a list of email recipients who will receive an emailmessage when the notification is triggered. The RECURRENT columnindicates whether the notification is single or recurrent, as describedpreviously. The TARDY_DATETIME column indicates the date and time atwhich the notification is to be considered tardy, which would cause atardy notification to be triggered. The TARDY_SIGNALLED column indicateswhether a tardy notification has been sent.

For each folder share that is established between two parties, an entryis made in table 216, FOLDER_SHARES. The system assigns a uniqueidentifier to each share and stores the identifier in theFOLDER_SHARE_ID column. The DATE_CREATED column indicates the date andtime at which the share was initiated. The CREATED_BY_USER_ID columnindicates the user that initiated the share. The SOURCE_FOLDER_ID columnidentifies the source folder for the share. The DESTINATION_COMPANY_IDcolumn indicates the company with which documents are being shared(i.e., the receiving party). The ACCEPTED_BY_USER_ID column identifiesthe user who accepted the share on behalf of the receiving company. TheDESTINATION_FOLDER_ID identifies the destination folder for the share(the folder to which documents are applied). TheRECURRENT_SHARE_PROFILE_ID column indicates the sharing profile whichspecifies the list of document types to be included in a recurringshare, as described below. The STATUS column indicates the currentstatus of the share, that can include values for initiated, accepted,declined and pended.

When a share is established, the sharing company may indicate that aspecific list of documents be applied to the destination folder. Foreach such document, an entry is made in table 206,FOLDER_SHARE_DOCUMENTS. The FOLDER_SHARE_ID column indicates theassociated share. The DOCUMENT_ID column indicates the document to beshared. The DOC_TYPE_ID indicates the document's type at the time theshare was initiated.

When a recurrent share is established, the sharing party must specifyone or more document types to be applied to the receiving party'sfolder. While the user can specify a new list of document types eachtime a share is created, the system allows each company to establish atype list that can be reused and applied to multiple shares tofacilitate this selection process. For each list of document typesassociated with a recurring share, an entry is made in table 208,FOLDER_SHARE_PROFILES. The system assigns each profile a uniqueidentifier which is stored in the SHARE_PROFILE_ID column. TheDESCRIPTION column stores a textual description of the list. TheDOC_TYPE_LIST_ID column identifies the document type list that isassociated with the profile. The IS_GLOBAL column indicates whether theprofile is made available as a pre-defined list or if it is associatedwith only a single share. For each document type included in a shareprofile list, an entry is made in table 210,FOLDER_SHARE_PROFILE_DOC_TYPES. The SHARE_PROFILE_ID column indicatesthe profile in which the document type is included, and the DOC_TYPE_IDindicates the document type to be included.

Referring to table 212, COMPANY_FOLDER_ATTRIBUTE_MAPS, the system canmaintain a mapping between the folder attributes of two companies. Sucha mapping can be used during the document sharing process toautomatically assign attribute values to the receiving party's folder.For each attribute in one company's folder attributes that correspondsto an attribute in another company's folder attribute, an entry is madein this table. The SOURCE_COMPANY_ID indicates the company associatedwith the source attribute. The SOURCE_ATTRIBUTE_ID identifies the sourceattribute. The DESTINATION_COMPANY_ID indicates the company associatedwith the corresponding destination attribute. TheDESTINATION_ATTRIBUTE_ID identifies the corresponding destinationattribute.

The default mapping of document types between two document type lists isdefined in table 202, DOCUMENT_TYPE_LIST_MAPS. As described above, eachdocument is stored in the repository in association with a folder and adocument type. If a transaction party wishes to share that document withanother transaction party, the receiving transaction party will view thedocument through its own folder. Since the two parties may not haveidentically-defined document lists, the default map in table 202 defineshow each document image having a given document type in the type listfor the sharing transaction party is placed in a document type and listas viewed by the receiving transaction party. Table 202 thereforeidentifies each combination of document type identifiers and documenttype list identifiers and associates each combination with a destinationdocument type identifier and document type list identifier combination.

While one or more preferred embodiments of the invention have beendescribed above, it should be understood that any and all equivalentrealizations of the present invention are included within the scope andspirit thereof. The embodiments depicted are presented by way of exampleonly and are not intended as limitations upon the present invention.Thus, it should be understood by those of ordinary skill in this artthat the present invention is not limited to these embodiments sincemodifications can be made. Therefore, it is contemplated that any andall such embodiments are included in the present invention as may fallwithin the scope and spirit thereof.

1. A system for managing documents at an electronic data repository,wherein the documents relate to a transaction involving parties remotefrom each other and having different roles in the transaction, thesystem comprising: an electronic data repository comprisingcomputer-readable database hardware and documents in electronic formatand that is accessed by a plurality of said parties that are remote fromthe repository; and a computer-readable device from which is executablea computer program that receives a said document in electronic formatfrom a first party of the plurality of the parties, stores the receiveddocument in the repository, permits one or more of the parties of theplurality of parties access to the received document, and prohibits allof the parties having access to the received document from modifying thereceived document in the repository once the received document is storedin the repository and from deleting the received document from therepository while any second party of the plurality of parties has accessto the received document.
 2. The system as in claim 1, wherein thecomputer program provides each said party of the one or more partiesaccess only to said documents stored in the repository that are withinone or more document sets corresponding to the last-mentioned saidparty, responsively to the last-mentioned party, the program definestypes of documents that are needed to complete a first said document setcorresponding to the last mentioned party, and the program notifies thelast-mentioned party when all the needed types of documents are storedin the repository in the first document set.
 3. The system as in claim1, wherein the computer program provides each said party of the one ormore parties access only to said documents stored in the repository thatare within one or more document sets corresponding to the last-mentionedsaid party, responsively to the last-mentioned party, the programmonitors predetermined documents, and the program notifies thelast-mentioned party when each of the monitored documents is stored inthe repository within a said document set corresponding to thelast-mentioned party.
 4. A system for managing documents at anelectronic data repository, wherein the documents relate to atransaction involving parties remote from each other and havingdifferent roles in the transaction, the system comprising: an electronicdata repository comprising computer-readable database hardware anddocuments in electronic format and that is accessed by a plurality ofsaid parties that are remote from the repository; and acomputer-readable device from which is executable a computer programthat receives a said document in electronic format from a first party ofthe plurality of parties, stores the received document in therepository, permits the first party access to the received document,permits a second party of the plurality of parties access to thereceived document responsively to the first party, and prohibits all ofthe parties having access to the received document from modifying thereceived document in the repository once the received document is storedin the repository and from deleting the received document from therepository while at least one said party other than the first party hasaccess to the received document.
 5. Within a transaction involving aplurality of parties remote from each other and having different rolesin the transaction, a computerized method for managing documents relatedto the transaction and controlling access to the documents, the methodcomprising the steps of: providing an electronic data repositorycomprising computer-readable database hardware and documents inelectronic format that is accessed by a plurality of said parties thatare remote from the repository; receiving in electronic format a firstdocument that relates to the transaction from a first party of theplurality of parties; storing the received first document in therepository; permitting the first party access to the first document;permitting a second party of the plurality of parties access to thefirst document responsively to the first party; prohibiting all of theparties having access to the first document from modifying the firstdocument in the repository once the first document is stored in therepository and from deleting the first document from the repositorywhile at least one said party other than the first party has access tothe first document; receiving in electronic format a second documentthat relates to the transaction from the second party; storing thereceived second document in the repository; permitting the second partyaccess to the second document; and prohibiting all of the parties havingaccess to the second document from modifying the second document in therepository once the second document is stored in the repository and fromdeleting the second document from the repository while at least one saidparty other than the second party has access to the second document. 6.Within a transaction involving a plurality of parties remote from eachother and having different roles in the transaction, a computerizedmethod for managing documents related to the transaction and controllingaccess to the documents, the method comprising the steps of: providingan electronic data repository comprising computer-readable databasehardware and documents in electronic format that is accessed by aplurality of said parties that are remote from the repository; and foreach of a plurality of documents that arise sequentially from and duringthe transaction, receiving in electronic format the document from arespective first party of the plurality of parties, storing the receiveddocument in the repository, permitting the first party access to thereceived document, permitting a respective second party of the pluralityof parties access to the received document responsively to the firstparty, prohibiting all of the parties having access to the receiveddocument from modifying the received document in the repository once thereceived document is stored in the repository and from deleting thereceived document from the repository while at least one said partyother than the first party has access to the received document, andreceiving in electronic format from the second party a next sequentialdocument that relates to the transaction.
 7. The system as in claim 1,wherein at least one of said parties of the plurality of partiescomprises a plurality of entities that are not remote from each other,wherein the computer program defines, responsively to the at least oneparty, access rights among the entities, and wherein, based on theaccess rights, the computer program permits the entities access todocuments that are stored in the repository and to which the computerprogram permits the at least one party access.